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FEAGssHtute 

Agenda 


•  A  short  introduction  to  the  FEAC  DoDAF  Certification 
Program 

•  Overview  of  DoDAF  2.0 
-  Changes  from  1.5 

•  Six  Step  Process  for  Planning 

•  Examples 

—  Example  questions  and  corresponding  views 
—  Example  planning  example 


The  FEAC  DoDAF  Program 

•  FEAC  was  founded  in  2001  and  has  certified  over  1600  architects 

•  FEAC  offers  DoDAF  education  and  training  that  leads  to  FEAC  Certification, 
which  is  given  by  California  State  University  East  Bay  and  can  earn 
graduate 

•  The  program  consists  of  five  courses,  four  of  which  can  be  taken  for 
graduate  academic  credit  from  the  Department  of  Engineering  at  CSUEB 

•  FEAC  has  a  relationship  with  National  University  (www.nu.edu)  who 
accepts  these  units  into  their  MS  in  Engineering  Management  program 
with  a  specialty  in  Enterprise  Architecture.  The  remainder  of  that  degree 
courses  is  offered  online. 

•  Students  learn  how  to  plan,  develop,  model,  implement  and  do  EA 
analysis  for  an  actual  DoDAF  project  throughout  the  program  and 
delivered  as  a  practicum 

•  FEAC  also  offers  short  workshops  and  DoDAF  boot  camps,  as  well  as 
TOGAF  9  certification  courses 
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The  DoDAF  Courses 


•  The  five  basic  FEAC  courses  are  designated  by  the  following 
course  numbers;  depending  on  whether  you  are  taking  the 
program  for  CEU  or  graduate  academic  units: 

-  EXSP  8680/ENGR  7806  Framework  Basics 

—  EXSP  8681/ENGR  7807  Planning  for  Architecture  Development 
and  Use 

—  EXSP  8682/ENGR  7808  Framework  Views  and  Models 

—  EXSP  8683/ENGR  7809  Advanced  DoD  Architecture  Modeling 
and  Analysis 

—  EXSP  8684  DoDAF  Practicum/Thesis 

•  We  also  provide  an  Elective  TOGAF  Course  for  those 
wanting  TOGAF  8.1.1  Certification,  which  qualifies  those 
who  want  to  TOGAF  9  to  take  the  Bridging  Examination 


Organizations  that  have  sent  students  to  F EAC  for  Certification 


FEAGsHfut& 


Government 

Army  Def  Med  Log  SS 

Army  AIMD  TRADOC 

Air  Force  HQ  OSSG 

Air  Force  AIMD  TRADOC 

Air  Force  USJFCOM 

Air  Force  US  PACOM 

Air  Force  US  STRATCOM 

Bureau  of  Engraving  &  Printing 

City  of  Glendale,  CA 

City  of  Virginia  Beach 

DOD  OSD  BMSI 

Department  of  Commerce  -  NTIA 
Department  of  Commerce  PTO 
Department  of  Education  SFA 
Department  of  Education  HQ 
Department  of  State 
DOI  CIO 
DOI OSM 
DISA 

HHS  -ASBTF-OIRM 
FDA 

Federal  Railroad  Administration 
FERC 

Forest  Service 

GAO 

GSA 

IRS 

Joint  Forces  Command 

Lawrence  Livermore  National  Labs 

National  Park  Service 

Navy  ONR 

Navy  NAVSISA 

NASA  HQ 

NASA  Centers 

NOAA 

Office  of  the  Comptroller  of  the  Currency 

OMB 

OPM 

Security  and  Exchange  Commission 

Smithsonian 

Treasury  -  US  Mint 

USDA  HQ 

USDA  RMA 

US  Postal  Service 

US  Coast  Guard 

US  Commerce  Department 

US  Patent  and  Trademark 

US  PACOM/J2T2 

US  Senate 

University  Of  Leuven  (Belgium) 

Veterans  Administration 
VA  Veterans  Benefits  Administration 
White  House-EOP 


Industry 

Aerospace  Corporation 

AMIT 

AMS 

Analytics  and  Mechanics 

Assoc 

Anteon 

Apteon 

Arinc 

BAE  Systems 

BEA 

Boeing 

Booz  Allen  Hamilton 
Burk  Consortium 
CACI 

Conquest-Boeing 

CSC 

Dell 

DiamondCluster 

International 

DigitalNet 

Eagan  McAllister 

East  Bank  Technologies 

ERPi 

General  Dynamics 
GroupoActivity  (Spain) 
Headstrong 
Hewlett  Packard 
IBM 

Independent  Consultants 
Information  Dynamics 
Johns  Hopkins  University- 
APL 

Knowledge  Code 
L-3  Communications 
Lockheed  Martin  Co 
Mitre 

Northrup  Grumman 
NTT  Data  Agilnet  (Japan) 
Oracle 
PacTel 

Phase  One  Inc 

Raytheon 

RG2 

RGS  Assoc 

Rose  International 

RSIS 

SAIC 

Samsung  (Korea) 

Schafer 
Sci  Group 
ScotCro 
SKCC  (Korea) 

SRA 

Stanley  Associates  Inc 
Summaria  Sys  Inc 
Titan 

VAAP  Technologies 


FEAGssHtute 

Goals 


•  Understanding  how  to  identify  required  data 
and  select  DoDAF  described  models  based  on 
stakeholder  questions 


FEAG"*® 

DoD  Architecture  Framework  2.0 

•  What  it  is: 

-  Guidance  on  the  types  of  data  and  relationships 
needed  to  document  a  DoD  architecture  in  a  standard 
way  (new  in  2.0) 

—  Guidance  on  format  and  content  for  a  standard  set  of 
DoDAF  Described  Models  for  describing  architectures 

—  High  level  meta-process  for  using  the  DoDAF 

•  What  it  isn't: 

-  A  specific  architecture 

-  A  tool 

-  A  detailed  architecture  development  process 


FEAG 


imiiCufe 


DoDAF  V2.0  Vision 


t  11 


Lin 


pas 


hb  o*rds 


Gr3 


phical  Depictions  Reference  Models  Fusion  Products 


PfWR 


Views  for  Other 
Stakeholders 


Com 


Posite  Prod 


ucts 


ata Elements  Bus**  Structured  Knowledge 

Base  -  Common  Model 


Architecture  Information 


Views  for  the  Architect 
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FEAC£sHtiit6 

Levels  of  Architecture 


DoD  Enterprise 


System  Context 
SoS  Architectures 
FoS  Architectures 


Capability  Based 


fea®-  DoDAF  V2.0  Viewpoints 


New  in  V2.0 


Data  models  split  out  into 
separate  Viewpoint  in  V2.0 


Services  views  split  out  into 
separate  viewpoint  in  V2.0 
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FEAGsHfut& 

Views  Are  Models 

Not  Pictures 

•  Models  have  a  standard  semantic  interpretation 
—  Rules  for  correctness  and  consistency 

•  Most  DoDAF  described  models/views  have  a  graphic 
template 

•  The  graphic  is  backed  up  with  dictionary  entries  (based  on 
data  entities  and  relationships  from  DM2): 

—  Data  elements  provide  definitions  and  descriptions  of  items  in 
the  graphic 

plus 

—  Additional  supporting  information  and  relationships  to  other 
architecture  elements 

•  The  data  elements  integrate  the  set  of  views 

-  Views  share  data 
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FEAG^® 

DoDAF  As  Guidance 


•  Views  have  options  discussed  in  Volume  II 

-  Choices  of  things  like: 

•  Techniques/notations 

•  Level  of  detail 

•  All  views  may  be  tailored 

—  Graphic  conventions 

-  Techniques  to  manage  complexity 

-  Edits  of  dictionary  entries:  changes  to  data 
elements 
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Unified  Profile  DoDAF  and 

MoDAF:  UPDM 

OMG  Standard:  provides  a  UML  2  and  optional 
SysML  profile  for  expressing  DoDAF  and  MoDAF 
model  elements 

Provides  identification  of  data  included  in  DoDAF 
described  models 

—  Used  to  be  included  within  DoDAF  volumes 

—  Now  included  in  separate  document 

—  Enhances  and  refines  DM2  in  DoDAF 

Provides  way  of  writing  DoDAF  described  models 
in  UML 

—  UML  is  a  notation,  not  a  methodology 


UPDM  Goals 


Enhance  the  quality,  productivity,  and 
effectiveness  associated  with  enterprise  and 
systems  of  systems  architecture  modeling 

Promote  architecture  model  reuse  and 
maintainability 

Improve  tool  interoperability  and 
communication  between  stakeholders 

Reduce  training  impacts  due  to  different  tool 
implementations  and  semantics 


FEAG^° 


Architecture  Planning 
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FEAGsHfut& 

Six  Step  Process  (V2.0)  - 
The  Planning  Perspective 


Scoping 

Architecture  Work 


— o— 

Determine  the 
intended  use  of 
the  architecture 


Planning  the 
Architecture  Project 
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FEAGsHhjte 

What  Does  the  Six  Step 
Process  Do  for  Planning? 

The  Six  Step  Process  is  important  to  the  identification  of 
required  data  and  selection  of  views  together  with  their 

options  and  tailoring 


•  Performance  of  Steps  1-4  yields  information  for  your  AV- 
1: 

-  Purpose  and  stakeholders 

-  Scope 

-  Views  with  options  and  tailoring 

•  Planning  for  Steps  4-6  yields  constraints  on  view  options 
and  tailoring  based  on  development  and  analysis 
processes 
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FEAC™ 

Step  1:  Determine  Intended  Use 
The  Problem  Statement 


•  What  questions  need  to  be  answered? 

•  Are  there  specific  strategic  objectives  to  be 
satisfied? 

•  Are  there  specific  trade  offs  to  be  considered? 

•  What  critical  issues  need  to  be  addressed? 

•  How  is  the  EA  used  to  support  key  decision¬ 
making  processes? 

•  What  types  of  analysis  need  to  be  supported? 
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FEAC“ 

Why  Is  Purpose  Important? 


•  Architecture  is  a  tool  to  support  decision 
making 

-  If  you  don't  know  what  you  are  going  to  use  it 
for,  there  is  a  good  chance  it  won't  be  useful 

-  You  need  to  identify  and  understand  the 
different  purposes  of  different  stakeholders 

•  Architectures  can  be  expensive  to  build 

-  Doesn't  make  sense  to  build  one  if  you  don't 
plan  to  use  it! 
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FEACp*'  ifut& 


Why  Is  Purpose  Important? 


PURPOSE 


VIEWS 

DETAIL 

COMPLETION 
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FEAG^® 

Step  2:  Determine  Scope 


•  Operational  bounds 

—  What's  the  enterprise,  what  level  of  architecture 
—  What  mission(s),  functions,  and  organizations 

-  What  geographical  context 

•  Constraints  on  technology  to  be  considered 

•  Timeframes 

-  As-ls,  To-Be,  phasing  and  evolution 

•  Specific  project  schedule  and  resource  constraints 
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FEAGsHtut* 

Step  3:  Determine  Data  Required  to 

Support  Architecture  Development  - 

Think  About  Architecture  Primitives 

(DoDAF  Conceptual  and  Logical  Data  Model  (DM2)  Entities) 


Performers 

•  Systems 

Activities 

•  Services 

Information 

•  Rules 

elements 

•  Standards 

Events/triggers 

•  Locations 

Capabilities 

•  Measures 

Goals 

•  Projects 
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FEAGsl^° 

Step  4: 
and 


Collect,  Organize ,  Correlate, 
Store  Architecture  Data 


Collect,  Organize, 
Correlate,  and  Store 
Architecture  Data 


•Automated  repositories 

•  Activity  Models 

•  Data  Models 

•  Dynamic  Models 

•  Organizational  Models 

•  Metadata  registration 


Emphasis  in  planning  is  how 
data  will  be  organized 

That  is,  what  DoDAF  views  will 
eventually  be  used,  including 
options  and  tailoring 

This  tells  us  what  the  meta¬ 
data  should  be  and  identifies 
repository  requirements 

This  tells  us  what  needs  to  be 
collected  and  how  it  should  be 
correlated 
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FEAGslnfi  _AII  Viewpoint  Views  Capture  Information 

That  Applies  to  the  Architecture  Overall 


Overview  and  Summary  Information  (AV-1) 

•  Identification 

-  Name 
-Architect 

-  Organizations  Involved 

-  When  Developed 

•  Purpose 

-Analysis  Needs 

-  Decision  Support  Needs 

•  Scope 

-  Views  and  Products  Used 

-  Time  Frames  Addressed 

•  Context 

-  Mission 

-  Geographical 

-  Rules,  Criteria,  and  Conventions 
Followed 

•  Findings:  Results,  Recommendations 

•  Tools  and  File  Formats 


Integrated  Dictionary  (AV-2) 


At  a  minimum,  the  integrated  Dictionary 
is  a  glossary  with  definitions  of  terms 
used  in  the  given  architecture 
description.  Each  labeled  graphical  item 
in  the  graphical  representations  should 
have  a  corresponding  entry  in  the 
Integrated  Dictionary. 
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FEAG^° 


Example  Questions  Mapped  to 

Views: 

Enterprise -Level  Architecture 

Capability  Management 
Portfolio  Management 
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FEAG 


institute 


Example  Capability  Management 

Questions 


Question 

Required  Data  Types 

Views 

How  do  the  capabilities  relate  to 
enterprise  strategy  and  goals? 

Vision 

Goals 

Desired  Effects 

Capabilities 

Relationship  between  capabilities 
and  goals 

Vision  (CV-1) 

Are  there  dependencies  among 
the  capabilities? 

Capabilities 

Relationships  among  capabilities, 
including  dependencies 

Capability 

Dependencies 

(CV-4) 

How  will  capability 
performance  be  measured? 

Capabilities 

Performance  Measures 

Relationships  of  capabilities  to 
performance  measures 

Capability 

Taxonomy 

(CV-2) 
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FEAGsH1ute 

Example  Capability  Management 
Questions  (continued) 


Question 

Required  Data  Types 

Views 

When  will  the  capabilities  be 
available  and  what  projects 
will  provide  them? 

Capabilities 

Projects 

Timeframes 

Relationships  among  the  above 

Capability 
Phasing  (CV- 
3) 

What  organizations  will  use  the 
capabilities? 

Capabilities 

Organizations 

Relationships  among  capabilities 
and  organizations 

Capability  to 
Organizational 
Development 
Mapping  (CV- 
5) 

Organizational 

Relationships 

Chart 

(OV-4) 
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FEAGsHfut& 

Example  Portfolio  Management 

Questions 


Question 

Required  Data  Types 

Views 

What  organizations  are  in 
change  of  which  projects? 

Organizations 

Projects 

Relationships  between 
organizations  and  projects 

Project 

Portfolio 

Relationships 

(PV-1) 

Organizational 

Relationships 

Chart 

(OV-4) 

What  are  the  timelines  for  the 
projects  and  are  there 
dependencies  among  them? 

Projects 

Timelines:  start  and  end  dates 
Dependencies  among  projects 

Project 

Timelines  (PV- 
2) 

Which  projects  are  delivering 
capability  configurations  that 
realize  which  capabilities? 

Projects 

Capabilities 

Relationships  between  projects  and 
capabilities 

Project  To 
Capability 
Mapping  (PV- 
3) 
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FE  ACpsHtut& 

Recommendation:  Basic  Views  for 
Enterprise-Level  Architectures 


•  Vision  (CV-1) 

•  Capability  Phasing  (CV- 

3) 

•  Capability 
Dependencies  (CV-4) 

•  Capability  to 
Organizational 
Development  Mapping 
(CV-5) 


•  Project  Portfolio 
Relationships  (PV-1) 

•  Project  Timelines  (PV- 

2) 

•  Project  to  Capability 
Mapping  (PV-3) 

•  Organizational 
Relationship  Chart  (OV- 

4) 


Plus  AV-1  and  AV-2,  as  always 
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FEAG 


inslstute 


Integration  of  Enterprise  Level  Architecture  Basic  Views 


VISION 

ccv-i) 


VALLE  AD  DEI:.  HOW 
CAPABILITIES  SUPPORT 
STRATEGIC  GOALS  & 
OBJECTIVES 


\7 


HIGH  LEVEL 
CAPABILITIES  ARE  THE 
SAME 


CAPABILITY 

DEPENDENCIES 

(CV-4) 


A 


VALLE  ADDED.  CAPABILITY 
DEPENDENCIES  AND 
SPECIALIZATIONS 


CAPABILITIES 

MATCH 


CAPABILITY 

PHASING 

(CV-3) 


VALUE  ADDED:  CAPABILITY 
CONFIGURATION  CHANGES 
OVER  TIME 


CAT  AD  ILIT1CG  AND 

CON  FIGU  RATI  ON  S  AR  E 
THE  SAME 


PROJECT  TO 
CAPABILITY  MAPPING 
(PV-3) 


'VALUE  ADDED.  LINKS 
CAPABILITIES  TO 
PROJECTS  THAT  DELIVER 
CONFIGURATIONS  TO 
IMPLEMENT  THE 
CAPABILITIES 


VALUE  ADD ED: PROJECT 
DELIVERY  TIMELINES  & 
CROSS  PROJECT 
DEPENDENCIES 


PROJECT 

TIMELINES 

(PV-2) 


PROJECTS 

MATCH 


DELIVERY  DATES  MATCH 


CAPABILITY  TO 
ORGANIZATIONAL 
DEVELOPMENT  MAPPING 
(CVS) 


/*■ 


PROJECTS 

MATCH 


PROJECT 

PORTFOLIO 

(PV-1) 


VA_L  E  ADDED.  LINKS 
PROJECTS  TO 
ORGANIZATIONS  THAT 
MANAGE  THEM 


ORGANIZATIONS 

MAP 


VALUE  ADDED:  MAPS 
ORGANIZATIONS  TO  CAPABILITIES 
AND  CONFIGURATIONS  THEY  USE 
WITH  DELIVERY  DATES 


ORGANIZATIONS  MAP 


ORGANIZATIONAL 
RELATIONSHIPS  CHART 
(OV-4J 


VALUE  AD  DEC- 

ORGANIZATIONAL 

RELATIONSHIPS 
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FEAG^° 


Example  Questions  Mapped  to 

Views: 

Solution-Level  Architecture 

Setting  Context  for  a  System, 

SOS,  or  FOS 
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FEAG11^0 

Example  Solution- Architecture 

Questions 


Question 

Required  Data  Types 

Views 

What  are  the  key  elements  of 
the  Operational  Concept  for  this 
architecture? 

Abstractions  of: 

Key  mission  process/activities 

Key  performers 

Key  resource  exchanges 

High-level 

Operational 

Concept 

Description 

(OV-1) 

How  are  mission  operations 
performed  (now  or  in  the 
future)? 

Mission  process/activities 

Resources  exchanged/inputs  & 
outputs 

Performers 

Activity  Model 
(OV-5) 
Operational 
Resource 

Flow 

Description 

(OV-2) 

Operational 

Resource 

Flow  Matrix 
(OV-3) 

FEAG 


Institute 


Basic  Operational  Views  Capture  the  Critical 
Mission  Relationships  and  Resource  Exchanges 


Activity  Model 


High-Level 
Operational 
Concept  Description 


High-level  graphical 
description  of  the 
operational  concept 
of  interest 


Operational  activities 
performed  and  their 
input/output 
relationships 


Operational 
Resource  Flow 
Description 


■  .11 

txternal 

I 

/  Performer 


Activity  1  p/rformt 
Activity  2  I  A 


Performers, 
Activities  for  each 
performers  and 
resource  needlines 


Operational 
Resource  Flows 
Matrix 


>urces  exchanged 
between  performers 
and  the 

relevant  attribute  of 
the  exchanges 


FEAC“ 

Example  Basic  Solution 
Architecture  Questions  (continued) 


Question 

Required  Data  Types 

Views 

What  systems/services  and 
what  are  their  interfaces 
(internal  and  external)? 

Systems/services 
System/service  interfaces 
Standards 

System  Interface 
Description  (SV-1) 
or  Services  Context 
Description  (SvcV-1) 
Standards  Profile 
(StdV-1) 

How  do  the  systems/services 
support  operations? 

Relationship  of 
systems/services  to 
performers 

Relationship  of 
systems/services  interfaces 
to  needlines 

Relationship  of 
systems/services  to  activities 

OV-2 

SV-1  /SvcV-1 
Operational  Activity 
to  Systems  Function 
Traceability  Matrix 
(SV-5)  or 

Operational  Activity 
to  Services 
Traceability  Matrix 
(SvcV-5) 

34 


Relationships  Between  OV-2  and  SV-l(SvcV-l) 
Put  IT  in  Context  with  Mission  Operations 


Location  B 


Activity  3 
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Standards  Profile  Identifies  Implementation 
Criteria  That  Govern  the  Given  Architecture 
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FEAGsHfut& 

Recommendation :  Basic  Views  for 
Solution-Level  Architecture 


•  High  Level  Operational 
Concept  Description  (OV- 
1) 

•  Operational  Resource 
Flow  Description  (OV-2 

•  Operational  Resource 
Flow  Matrix  (OV-3) 


•  Operational  Activity  Model 
(OV-5a,  b) 

•  Systems  Interface 
Description  (SV-1)  or 
Services  Context 
Description  (SvcV-1 ) 

•  Standards  Profile  (StdV-1) 

•  Capability  to  Operational 
Activity  Mapping  (CV-6)* 


Plus  AV-1  and  AV-2,  as  always 


*New  with  DoDAF  V2.0;  assumes  a  Segment-Level  or  Enterprise-Level  architecture 
related  to  the  Solution-Level  architecture. 
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FEAGsl"u,e  These  Basic  Views  Link  to  Each  Other 


STANDARDS  PROFILE  (StdV-1) 


VALUE  ADDED:  COMPLETE  LIST 
OF  RELEVANT  STANDARDS 
WITH  OPTIONS  & 
PARAMETERS 


CONCEPT 

ROLES  &  MISSIONS  SET 
SCOPE  FOR  ACTIVITY 
MODEL 


OPERATIONAL  ACTIVITY  MODEL  (OV-5) 


VALUE  ADDED:  BUSINESS/MISSION  PROCESS  & 
RELATIONSHIPS  AMONG  ACTIVITIES  AND 
RESOURCE  EXCHANGES 


•  ACTIVITIES  MAP  TO  OV-2 
PERFORMERS 

■  I/OS  MAP  TO  NEEDLINES 

•  PERFORMERS  OF  ACTIVITIES, 

IF  SHOWN  ON  OV-5,  MAP  TO  OV-2 
PERFORMERS 


STANDARDS  APPLY  AT 
SYSTEM  TO  SYSTEM 
INTERFACES 


OPERATIONAL  CONCEPT 
CONNECTIVITY  &  RESOURCE 
EXCHANGES,  IF  SHOWN  ON  OV-1, 
MAP  TO  OV-2  NEEDLINES  & 
RESOURCE  EXCHANGES 


SYSTEMS  INTERFACE  DESCRIPTION 
(SV-1) 


INPUT/OUTPUT 
LABELS  MAP  TO 
OPERATIONAL 
RESOURCE 
EXCHANGES  (NOT 
ALWAYS  ONE-TO- 
ONE) 


RESOURCE  EXCHANGES 
ASSOCIATED  WITH  EACH 
NEEDLINE  ARE  DETAILED  IN 
OV-3 


OPERATIONAL  RESSOURCE  FLOW 
DESCRIPTION  (OV-2) 


OPERATIONAL  RESOURCE  FLOW  MATRIX 
(OV-3) 

VALUE  ADDED:  INDIVIDUAL 
RESOURCE  EXCHANGES 
ASSOCIATED  WITH  EACH 
NEEDLINE  & 
PERFORMANCE 
REQUIREMENTS 


:1t 


VALUE  ADDED:  STATEMENT  OF 
OPERATIONAL  PERFORMERS, 
ACTIVITIES,  AND  CRITICAL  RESOURCE 
EXCHANGE  NEEDS 


VALUE  ADDED:  STATEMENT  OF  LOCATIONS,  SYSTEI\ 
&  INTERFACES 


•  PERFORMERS  ARE 
ASSOCIATEAD  WITH  SYSTEMS  AND 
LOCATIONS 

•  EACH  OPERATIONAL  NEEDLINE  MAPS 
TO  ONE  OR  MORE  SYSTEM 
INTERFACES 
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Segment-Level  Architecture 

Capability  Focus 
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Recommendation:  Basic  Views  for 
Segment- Level  Architecture 

•  Combination  of  Enterprise  and  Solution  Level  core  views 

•  If  the  Segment  is  used  to  manage  the  investments  and  portfolio  for 
the  capabilities  included  in  the  segment,  then  the  Enterprise  Level 
core  views  apply 

•  If  the  Segment  is  used  to  coordinate  a  set  of  Solution  Level 
architectures,  then  the  Solution  Level  core  views  apply  to  set  the 
business  context  and  document: 

-  Relationship  of  major  systems  to  high-level  business  process 

-  Interfaces  among  business  processes  and  among  systems 
necessary  to  ensure  interoperability 
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Additional  Example 
Questions  Mapped  to  Views 
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Example  Dynamic  Behavior  (Timing 
&  Sequencing)  Questions 


Question 

Required  Data  Types 

Views 

What  scenarios  explain 
the  concept  of  operation 
or  key  performance  or 
security  issues? 

Events 

Messages 

Performers/systems/services 
Relationship  among  the  above 

Event/Trace 
Descriptions: 
Operational  (0V-6c) 
Systems  (SV-IOc) 
Services  (SvcV-IOc) 

What  are  the 
states/statuses  that  key 
elements  of  the 
architecture  have  and 
how  do  they  change? 

States  for  a  given  element  of  the 
architecture 

Transitions 

Events 

Relationships  among  the  above 

State  Transition 
Descriptions: 
Operational  (OV-6b) 
Systems  (SV-lOb) 
Services  (SvcV-lOb) 

What  are  the  rules  that 
constrain  operations, 
systems  and/or 
services? 

Rules 

Relationships  of  rules  to  other 
elements  of  the  architecture 

Rules  Models: 
Operational  (OV-6a) 
Systems  (SV-lOa) 
Services  (SvcV-lOa) 
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Example  Domain  Data  Questions 


Question 

Required  Data  Types 

Views 

What  are  the  shared 
mission/business 
concepts  and  their 
relationships? 

Entities 

Attributes 

Relationships  among  the  above 

Conceptual  Data 

Model 

(DIV-1) 

What  is  the  logical 
structure  of  the  key 
structured  shared  data  in 
the  architecture? 

Entities 

Attributes 

Relationships  among  the  above 

Logical  Data  Model 
(DIV-2) 

What  is  the  physical 
structure  of  the  key 
structured  shared  data  in 
the  architecture? 

Entities,  Attributes,  and 

Relationship  among  the  above  or 
File  Structures  or 

Message  Structures  or  ? 

Physical  Data  Model 
(DIV-3) 
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Example  Transition  Planning 

Questions 


Question 

Required  Data  Types 

Views 

When  will  new 
system  s/services  be  avail* 

Systems/Services 

jfJMeframes 

Relationship  among  the  above 

Systems  Evolution 
Description  (SV-8)/ 
Services  Evolution 
Description  (SvcV-8) 

What  IT  performance 
improvements  should  be 
expected  at  key 
transition  milestones? 

Systems/Services 

Performance  measures 
Relationships  among  the  above 

Systems  Measures 
Matrix  (SV-7)/ 

Services  Measures 
Matrix  SvcV-7) 

What  are  the  trends  in 
systems/services  and 
standards  and 
associated  personnel 
skills  that  may  impact  IT 
during  the  transition 
period? 

Systems/Services  Areas, 

Categories,  and  Standards 
Timeframes 

Forecasts 

Systems  Technology 
and  Skills  Forecast 
(SV-9)/  Services 
Technology  and  Skills 
Forecast  (SvcV-9) 
Standards  Forecast 
(StdV-2) 
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Example  Matrix/Mapping  Questions 


Question 

Required  Data  Types 

Views 

Which  systems/services 
interface  with  which 
other  systems/services? 

Systems/services 
Systems/services  interfaces 

Systems2  Matrix  (SV- 
3) 

Systems-Services 
Matrix  (SvcV-3a) 
Services2  Matrix 
(SvcV-3b) 

How  do  services  relate 
to  capabilities? 

Services 

Capabilities 

Relationships  among  the  above 

Capability  to  Services 
Mapping  (CV-7) 

What  are  the  key  attributes 
(such  as  throughput)  of  the 
system/services  resources 
flows? 

System/Service  Interfaces 
System/Services  Resource  Flows 
Attributes  of  Resource  Flows 

Systems  Resource 

Flow  Matrix  (SV-6)/ 
Services  Resource 

Flow  Matrix  (SvcV-6) 
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imiirute 


Mapping  Summary 


PV-1 


Project 


PV-3 


Organization 


SV-3 

A 


Capability 


CV-6 


Operational 

Activity 


SV-5  Systems/Servic 

es 

SvcV-5 


SvcV-3 


Mappings  help  check  for  architecture  consistency. 
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Other  Example  Questions 


Question 

Required  Data  Types 

Views 

What  organizations  are 
included  in  the  architecture 
and  how  do  they  relate  to 
the  performers  or  other 
elements  of  the 
architecture? 

Organizations 

Reporting/management 

relationships 

Relationships  of  organizations 
to  other  elements  of  the 
architecture 

Organizational 
Relationships  Chart 
(OV-4) 

What  are  the  key 
communications  IT  that 
support  the 
systems/services 
interfaces? 

Systems/services 
Communications  systems, 
technologies  &  protocols 
Relationships  among  the 
above 

Systems  Resource 

Flow  Description  (SV- 
2)1  Services  Resource 
Flow  Description 
(SvcV-2) 

What  are  the  systems 
functions/services  and 
the  data  flow  among 
them? 

Systems  functions/services 

Data  flows  among  the  systems 
functions/producer-consumer 
flows  among  the  services 

System  Functionality 
Description  (SV-4)/ 
Services  Functionality 
Description  (SvcV-4) 
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Planning  Example: 
Solution  Level  Architecture 

(Example  from  FEAC Certified 
Enterprise  Architect  CEA  Study 
Guide,  McGraw  Hill,  2011  by  Rao, 
Reedy,  <&  Bellman) 


FEAG^® 

Context  for  Example 


•  Case  Study:  Hypothetical  Richard  M.  Nixon 
(RMN)  civil  aviation  air  field  that  wants  to 
grow  over  the  next  15  years  into  a  viable 
option  to  LAX 

-  Extract  of  Case  Study  from  book 
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Purpose 

•  Define  upgraded  passenger  identification 
business  processes  for  RMN  Airport 

•  Provide  guidance  for  the  acquisition  of  the  set 
of  applications  and  common  database  to 
support  these  upgraded  business  processes 
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Stakeholders  and  Issues  (1) 

Port  Authority,  RMN  Management,  and  DHS 

•  Will  the  new  business  processes  and  applications 

meet  government  regulations  and  requirements? 
That  is,  what  types  of  passenger  identification  data 
are  required? 

•  Who  needs  what  data  and  who  should  provide  the 
data? 

•  How  do  the  new  processes  improve  confidence  in 
passenger  identification?  (Measures  include  speed, 
availability,  and  consistency  of  data) 
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Stakeholders  and  Issues 


RMN  Management  and  DHS 

•  How  many  personnel  will  be  needed  for  the  new 
business  processes? 

•  Will  the  personnel  need  additional  skills? 

•  When  will  any  additional  personnel  be  needed? 

•  Will  new  facilities  be  required?  If  so,  when  will  they 
become  available  for  use? 
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Stakeholders  and  Issues  (3) 

RMN  Management 

•  When  will  the  upgraded  processes  and  their 
supporting  applications  be  ready  for  use? 

•  What  performance,  in  terms  of  passengers  per  hour, 
should  be  expected  from  the  new  processes? 
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Stakeholders  and  Issues 


RMN  Management  and  RMN  Employees 

•  What  are  the  upgraded  business  processes? 

•  How  do  the  new  applications  support  the  business 
processes? 

•  How  do  the  new  applications,  services,  and 
databases  integrate  with  other  RNM  IT? 

•  What  infrastructure  will  be  required? 

•  What  standards  will  the  new  applications, 
systems/services,  and  databases  use? 


54 


feag— 

Stakeholders  and  Issues  (5) 

DHS,  Passenger  Airlines,  and  FAA 

•  What  are  the  upgraded  business  processes? 

•  How  do  we  use  the  new  business  processes  and 
applications  to  get  the  data  we  need? 
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Scope 

•  Solution  Level  architecture  for  the  Passenger 
Management  Segment  of  the  RMN  Airport  enterprise 

•  Mission/function/organizational  bounds:  Passenger 
identification  business  services  for  RMN 

•  Geographic  bounds:  RMN  Airport  grounds  and  associated 
business  offices 

•  Timeframe:  To-Be  (Present  +  10  Years  timeframe  that 
includes  international  travel 

•  Technology  Constraints:  Overall  compatibility  with  RMN 
enterprise  IT  standards  and  Federal  (DHS/FAA)  data 
standards;  using  COTS  components  and  infrastructure 

•  Expected  Analysis:  Business  Case  Analysis;  Acquisition 
Requirements  Analysis 
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Partial  Mapping  of  Questions  to  Required 
Data  Types  and  Views  (1) 


Question 

Stakeholders 

Required  Data 

Types 

Views 

What  types  of 

passenger 

identification  data 

are  required? 

Port 

Authority, 

RMN  Mgmt, 

DHS 

Data  model 

Logical  Data  Model 

(DIV-2)  modeling 

information 

exchanges/activity 

I/Os 

Information 

Exchanges 

Operational 

Resource  Exchange 

Matrix  (OV-3)  with 

basic  columns 

I/Os  from  activities 

Activity  Model 

(OV-5) 

Government 

regulations  and 

standards 

Standards  Profile 

(StdV-1)  tailored  to 

include  regulations 

FEAG1^0 


Partial  Mapping  of  Questions  to  Required 
Data  Types  and  Views  (2) 


Question 

Stakeholders 

Required  Data 

T  ypes 

Views 

Who  needs  what 

data  and  who  should 

provide  the  data? 

Port 

Authority, 

RMN  Mgmt, 

DHS 

Performers 

Relationships  of 

performers  to 

activities 

Operational 

Resource  Flow 

Description  (OV-2) 

Information 

Exchanges 

Operational 

Resource  Flow 

Matrix  (OV-3) 

I/Os  from  activities 

Activity  Model 

(OV-5) 

How  do  the  new 

processes  improve 

confidence  in 

passenger 

identification? 

(Measures  include 

speed,  availability, 

and  consistency  of 

data) 

Port 

Authority; 

RMN  Mgmt; 

DHS 

Business  processes 

Activity  Model 

(OV-5)  tailored  to 

include  performance 

measures  and  goals 

Operational 

Resource  Flow 

Matrix  (OV-3)  with 

additional  columns 
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Partial  Mapping  of  Questions  to  Required 
Data  Types  and  Views  (3) 


Question 

Stakeholders 

Required  Data 

Types 

Views 

When  will  the 

upgraded  processes 

and  their  supporting 

applications  be 

ready  for  use? 

RMN  Mgmt 

Timeline  for 

application  and 

process  availability 

Systems/Services 

Evolution 

Description  (SV- 

8/SvcV-8)  tailored  to 

include  process 

definition  &  training 

completion  dates 

What  performance, 

in  terms  of 

passengers  per 

hour,  should  be 

expected  from  the 

new  processes? 

RMN  Mgmt 

Business  processes 

Activity  Model 

(OV-5)  tailored  to 

include  performance 

measures  and  goals 

Information 

Exchanges 

Operational 

Resource  Flow 

Matrix  (OV-3)  with 

Periodicity  column 

(average  and  worst 

case  numbers) 
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Partial  Mapping  of  Questions  to  Required 
Data  Types  and  Views  (4) 


Question 

Stakeholders 

Required  Data 

Types 

Views 

How  many 

personnel  will  be 

needed  for  the  new 

business 

processes? 

RMN  Mgmt; 

DHS 

Performers 

Operational 

Resource  Flow 

Description  (OV-2) 

Organizations  & 

Number  of 

personnel  who  are 

performers  per 

organization 

Organizational 

Relationships  Chart 

(OV-4)  tailored  to 

include  number  of 

personnel  per 

performer  group 
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Summary  of  Selected  Views 

From  Partial  Mapping 

•  OV-2:  performers  are  roles 

•  OV-3:  with  Needline  ID,  Information  Exchange  ID,  Description,  Media, 
Triggering  Event,  Producing  Performer  and  Activity,  Receiving  Performer  and 
Activity  columns,  Periodicity  (average  &  worst  case),  plus  other  columns 

•  OV-4:  with  map  to  performers  and  including  number  of  personnel  per 
performer/role 

•  OV-5:  including  performance  measures/goals  for  top  level  processes 

•  DIV-2:  Modeling  information  exchanges  and  activity  inputs/outputs 

•  SV-8:  including  process  definition  and  training  completion  dates 

•  StdV-1:  including  regulations;  use  FAATRM 
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Summary:  Traceability  to  Purpose 
Ensures  Useful  Architectures 


Architecture  Users/ 
Decision  Makers 

Have 


V 

Questions/Issues 


Support 


Fit-for-Purpose 

Views 


That 


Require 


V 

Data 


Architecture  Repository/ 
Structured  Knowledge 
Base 

/\  Feed  Consistent, 
1—1  Complete  Data 


Architects'  Views 
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